In today's increasingly data-driven and competitive business environment, the efficient storage and retrieval of data is often critical to business success. The use of SANs has become widespread as the ability to store and retrieve massive amounts of data from a large number of storage devices over a large geographic area is now becoming a business necessity. Not surprisingly, reducing the time it takes to store and retrieve data across a SAN is a goal of any such storage system.
FIG. 1 illustrates an exemplary conventional SAN 100 including a host computer 102, a fabric 104, a target 106 and one or more Logical Units (LUs) 108, which are actually logical drives partitioned from one or more physical disk drives controlled by the target's array controller. The host computer 102 includes an initiator 110 such as a Host Bus Adapter (HBA) or I/O controller for communicating over the SAN 100. A representative application 112 is shown running on the host computer 102. The fabric 104 may implement the Fibre Channel (FC) transport protocol for enabling communications between one or more initiators 110 and one or more targets 106. The target 106 acts as a front end for the LUs 108, and may be a target array (a single controller with one or more ports for managing, controlling access to and formatting of LUs), Just a Bunch Of Disks (a JBOD) (a collection of physical disks configured in a loop, where each disk is a single target and a LU), a Switched Bunch Of Disks (SBOD®), or the like. An example of a conventional target array is an EMC Symmetrix® storage system or an IBM Shark storage system.
In the example of FIG. 1, the application 112 may employ a file system protocol and may initiate read or write I/O commands 114 that are sent out of the host 102 through the initiator 110 and over the fabric 104 to target 106, where data may be read from or written to one or more of the LUs 108. When an I/O command 114 is transmitted, there is an expectation that the I/O command will be completed, and that it will be completed within a certain period of time. If the read or write operation is completed successfully, an I/O command completion notification 116 will be delivered back to the application 112. At other times, however, if a target 106 or LU 108 is overloaded or malfunctioning, the I/O command may not complete, and no I/O command completion notification 116 will be sent back to the application 112. In such a situation, the only feedback received by the application 112 may be an indication that the I/O command timed-out, and a reason code providing a reason for the timeout.
To assist a SAN system administrator in identifying problem targets 106 or LUs 108 and maintaining an efficient SAN with a balanced and fair LU workload, it is desirable to know the average I/O command completion time for I/O commands sent to each LU 108 in a target 106. In particular, it would be desirable for a system administrator to receive continuously updated LU-specific average I/O command completion time information for each LU in each target the initiator discovered in a dynamic manner. Such information would enable the system administrator to identify where latencies are being injected into the SAN or identify latencies that are worsening, and make adjustments accordingly. For example, if the average I/O command completion times for two different LUs 108 in the same target 106 are drastically different (e.g. greater than one second), this may be an indication that the LUs are unbalanced and that there is some unfairness at the target, and that perhaps the LU loads need to be re-balanced to achieve a greater degree of fairness. On the other hand, if the average I/O command completion times for all LUs 108 at a target 106 are high, this may be an indication that the target is receiving too many I/O requests and that more storage needs to be added so that some data can be shifted to the new target. In other words, it is desirable for the application to detect unfairness among LUs and/or overloaded conditions at a particular target.
However, conventional fabric-attached storage solutions do not provide average I/O command completion time information for an initiator 110 and target 106 in a SAN 100, or for multiple initiators and targets in a SAN. Conventional systems either do nothing, or wait for an initial I/O command failure to occur before taking corrective action such as limiting the outstanding I/O count. The problem with this approach is that by the time the storage device provides an indication that a problem exists, it may be too late to influence the storage device or it may become very expensive to react from an application point of view.
It should be noted that for directly attached and controlled storage such as conventional parallel Small Computer System Interconnect (SCSI) systems where the storage is directly connected to the host without an intervening target array, tools do exist for calculating the I/O command completion time for a particular I/O command and an average I/O command completion time, such as iostat -v, sysstat version 5.0.5, ©Sebastien Godard, the contents of which are incorporated by reference herein. In such systems, a statistics counter in the SCSI layer keeps track of I/O command completion times, and monitoring tools within the operating system display this parameter. However, the average I/O command completion time is merely an information-only health indicator, because directly-attached storage systems by their very nature cannot make use of this information to adjust storage allocations and improve the response times of I/O commands.
Therefore, there is a need to compute average I/O command completion times on a per-LU, per-target basis within a fabric-attached storage system to enable a driver within a host, or a system administrator, to make adjustments to improve the efficiency of the SAN.